Package Diagrams
Package diagram (pkg) = displays the organization of the system model based on package hierarchy where packages could be nested within each other.
Namespace = model element that is allowed to contain other named elements, included nested elements.
A model = one of four specialized kind of packages, this serves as the root of the package hierarchy. So in the example below, this is a package of the DellSat model.
Notations
There are 3 notations to explicitly convey namespace containment:
– Crosshair notation = solid line with circle crosshair used to show that Structure package is contained within the Domain package. This could also have been shown using the nested notation (stylistic preference only).
– Nesting notation = folders within the folders, such as the different structure folders under structure. These could have also been shown using crosshair notations.
– Qualified name string notation = used for space-efficiency. In figure 10.1, “Domain::Actors” is this notation to indicate that Actors package is contained within Domain package. Generally used when element’s owner is not shown in the same diagram. Two ways to write this:
o Fully qualified = Model::Domain::Actors
o Relative qualified = Domain::Actors
In figure 10.1, of the 17 package folders shown, six of them are within the default namespace of DellSat model package. The other are not contained within the default namespace; as noted above.
Dependencies
Dependencies = are the dashed lines with open arrowheads and indicates that the origin package has a dependency to the pointing package. The Test Case, Behavior and Structure packages depends on Requirements package
Importing Packages
Import packages = to bring other models into this model, noted by a dashed line with open arrowhead and keyword <<import>> above it.
Specialized Packages
To help partition the elements into a logically cohesive group, there are four specialized kinds of packages:
– Model
– Model library
– Profile
– View
Model = serves as the root of the containment hierarchy (or top level package). Has keyword <<model>> preceding the name or a small triangle in upper right corner of folder.
Model library = set of elements you intend to reuse (multiple models). Must have keyword <<modelLibrary>> above its name.
Profile = contains a set of stereotypes; stereotype = new kind of model element by adding properties, constraints or semantics to an existing model. Defines a new modeling language that can be used in the current model. View Figure 10.3.
View = package that contains a filtered subset of a model; selectively imports other packages, elements, and diagrams and represents an aspect of particular interest to the stakeholder. It conforms to a viewpoint = model element that contains following properties:
– Stakeholders = people who would find this viewpoint relevant
– Concerns = stakeholder questions that this view can answer
– Purpose = reason why this viewpoint exists
– Languages = lists the modeling languages used in this view
– Methods = list the set of rules to follow to construct this view
Look at Figure 10.3 as example.
<<conform>> special kind of dependency (dashed line open arrowhead) – conveys that “Reliability View” was constructed in accordance to the “Reliability Viewpoint”.
Elements of Package Diagrams
Elements can be contained within an element (nested); if parent deleted (container element), so is the child. Packages are a type of container. Can have hierarchy by use of imports or dependencies; packages containing packages. Packages also benefit from reuse (or model libraries which are intended purely for reuse). View is kind of package used to show particular view of model, such as performance or security.
[1] What is diagram kind in the frame label of a package diagram?
Diagram Kind for package is pkg, in this format:
The most significant types of packages used to organize models are “packages”, “model libraries” and “views”
[2] Which kinds of model element can be represented by package diagram?
[3] What generic term for model elements that contained in packages?Package = container for other model elements; elements that can go into package are called packageable elements, which can be blocks, activities, value types, etc.
[4] Where does model appear in package hierarchy?
Model = top level package in nested package hierarchy
Model Library = package that is designed to be reused
Package Hierarchy
[5] Name three potential organizing principles that might be used to construct package hierarchy
Some possible ways to organize a hierarchy:
– By system hierarchy = system level, subsystem level, component level, etc
– By process life cycle = requirements analysis, system design, etc
– By teams = requirements team, integrated product team (IPT), etc
– By type of model elements contained = requirements, behavior, structure
– By model elements that likely to change together
– By model elements organized to support reuse = model libraries
– Or any combination above
[6]How can you show a package diagram that one package contains another?
Containment relationship = relates parents to children within a package hierarchy; noted with a line with crosshair on parent end; shown in Figure 5.3. The containment hierarchy is shown in Figure 5.4. The containment hierarchy is shown graphically in Figure 5.3 and 5.5.
� 
à
[7] Which rule does package enforce for the named elements that are its members?
Namespaces = packages are also a namespace for all named elements within it; which defines a set of uniqueness rules to distinguish different named elements within it.
[8] How can you tell that a model element is a member of a package that owns the diagram? Qualified Name = shows the relative path to an element based on its place in the package hierarchy; noted by ::
[9] Write down qualified name for block B1 contained in package P1, which in turn is contained in M1
Importing Model Elements and Packages
Package Import = applies an entire package and all model elements of source package to target namespace
Element import = applies single model element
Name clash = two or more model elements in target namespace are same; rules for dealing with name clash:
– If imported element is name clash (child) of target namespace, then it is not imported
– If two or more imported elements are name clash (siblings), then neither imported
Visibility = determines whether member (element) can be imported; no SysML notation for this so just use notes/comments
[12] What is alias used for?
Alias = used to avoid name clashes; noted in the relationship lines in diagram
Another notation for importing packages using qualified names:
Dependency
[13] Name three common kinds of dependency
Dependency relationship shows that element in one end may change if its parent changes. Some common types of dependencies are: child = client, parent = supplier
– Use = client uses the supplier as part of definition
– Refine = client extends supplier, gives more details to supplier definition; often used in requirements analysis
– Realization = client implements supplier, the supplier is a bit more abstract and client implements it
– Trace = linkage between client and supplier without significant constraints;
[14] How are dependencies shown on a package diagram?
Dependency is noted by dashed line with open arrow, a <<guilemet>> keyword indicates the type of dependency:
Views and Viewpoints
[15] Name three properties of a viewpoint
[16] How do you represent a view V1, which confirms to viewpoint VP1, on a package diagram?
Viewpoint = perspective of interest to stakeholder that specify a view of model; includes properties that identify:
– Purpose or reason for perspective
– Stakeholders who have interest in this perspective
– Concerns that stakeholders want to address
– Languages used to present the view
– Methods used to establish the view
View = type of package that conforms to a viewpoint; imports set of model elements according to viewpoint; intended to model the stakeholders concerns. A conformance relationship is shown on diagram with dashed arrow from view to viewpoint.
